This invention relates generally to the field of developing computer software in integrated development environments and more particularly relates to constraining the amount of source code used by runtime analysis tools.
Computer software development has its own terminology and, herein at the beginning, a tutorial in definitions as used herein may be helpful. Software is object code and source code. Object code is the output from a compiler or assembler and is the code that is executable by the computer machine itself or can be used to create executable machine code. Source code is the input to a compiler or assembler typically written by a human in a source language, such as C++ or JAVA, and is capable of being read and edited by a human. In object-oriented programming (OOP) and other highly modular languages, a single general purpose portion of code, called an object within the computer program may execute multiple times for multiple purposes. An object includes data and/or one or more sets of instructions as routines or methods that define specific operations to be performed on the data. A number of objects can be “glued” together to build a component or an entire computer program with each object interacting with other objects or components in the computer program to perform desired operations. When one object invokes a particular routine in another object, the former object is said to be calling the routine in the latter object. General purpose objects in a computer program may support basic operations, e.g., displaying information to a software developer, printing information on a printer, storing or retrieving information from a database, etc. A component is generally larger than an object and is a specific portion of code that can also be reused across multiple applications; in other words, a component is standard software that can be pulled off a server and incorporated into new applications using a tool by software developers. For example, a calendar component may be used in several applications such as a scheduling application, a presentation application, a data base application to calculate employee's vacation and pay, etc. An application is a software program used by an end software developer; examples of applications include a scheduling client program or application wherein a person may schedule employees' work days; a word processing application; a presentation application to prepare slides for a talk; a database application in which to manipulate data; a spreadsheet application, etc. A tool is a software application that enables a software developer to write additional applications. Examples of tools include: a remote-accessing tool; a database tool to access and manipulate remote relational databases; a message queue tool to access and manipulate remote messages; an import tool to select files on a remote system to import into an ongoing software development project; a performance tool to access and configure remote performance; a tracing tool to trace execution of a program in a remote system, a file tool to access folders and files in a remote file system, etc. Thus, a software developer uses tools to pull components usually made up of objects from a local or remote server to create applications.
Software developers found it was first convenient to have all code generation tools under one umbrella, called an integrated development environment (IDE). Integrated development environments, as the name suggests, give the software engineer an environment having the tools for source code editing, compiling, linking, testing, debugging, and profiling seamlessly integrated. The advantage of using an IDE is that the software developer need not be concerned about the tool interfaces when moving from one phase of code development to the other. The IDE may track the phase of code generation and appropriately invoke the necessary tool. An example of a software development, analysis, and maintenance environment is GENERA which was developed by SYMBOLICS and LISP. For UNIX programmers, FUSE is an integrated development environment that has tools that include editors, program builders, source code managers, debuggers, cross-referencers, call graph browsers, file comparison tools, main page hypertext viewers, search tools, performance profilers, heap analyzers, program visualizers, and an optional C++ class browser. Other examples include IBM® VISUALAGE® C++ and VISUALAGE for JAVA™. VISUALAGE C++ provides an environment and toolset for multiplatform object-oriented application development with class libraries and frameworks to build applications on AIX®. VISUALAGE FOR JAVA is IBM's JAVA development environment to build web-enabled enterprise applications with support for building and testing JAVA applets, servlets, and ENTERPRISE JAVABEANS. There are other integrated development environments but basically, an integrated development environment provides a complete capability for building, editing, compiling, dynamically and statically analyzing programs, configuring, source browsing, and debugging, etc. IBM, AIX and VisualAge are trademarks of International Business Machines Corporation in the United States, other countries, or both while Java is a trademark of Sun Microsystems, Inc. in the United States, other countries, or both.
IBM and REDHAT developed an open source integrated development environment called Eclipse™ that supports C and C++ in addition to JAVA for software development. Eclipse software runs not only on the LINUX™ operating system but also other operating systems. There is special interest in the LINUX operating system because it is an open source operating system not belonging to a single entity but is owned and developed by the public. The Eclipse integrated development environment is thus an open source environment for creating, integrating and deploying application development tools across a broad range of computing technology. Eclipse software provides a common set of services and establishes the framework, infrastructure, and interactive workbench to build application software and related elements. Eclipse software includes, inter alia, a source code editor with code browsing and navigation features like code assist, syntax based color highlighting and integrated help facilities that uses a graphical software developer interface. Eclipse is a trademark of the Eclipse Foundation in the United States, other countries, or both while Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Functions incorporated into the tools of an integrated development environment may include debugging, tracing, profiling, and logging. Debugging locates and identifies errors in a computer program under development; tracing prints the values of the variables and identifies the conditions at a particular statement; profiling analyzes the performance of an application and ascertains where and if any problems occur; logging and other code coverage and testing tools are also problem detections tools of an integrated development environment.
Conventional debuggers support two primary operations to assist a computer software developer, the first of which is a “step” function that permits a software developer to process statements one at a time in a computer program and see the results of each instruction upon completion. The step operation provides a programmer with a large amount of information about a program during its execution but the task of stepping through hundreds or thousands of program instructions may be tedious and time consuming. In fact, the programmer may be required to step through many program instructions already known to be error-free before the desired set of instructions to be analyzed are executed.
A second operation supported by conventional debuggers is a breakpoint operation that permits a computer programmer to halt the execution of a computer program at a precise instruction. Used together, step operations and breakpoints simplify the debugging process. A computer program executes normally by a debugger until a breakpoint is reached, at which point the program stops execution and the debugger displays the results of the computer program to the programmer for analysis. The programmer then steps through the code line-by-line using the step operation. Consequently, a programmer is able to isolate and analyze a particular set of instructions without having to step through irrelevant portions of a computer program.
As mentioned, there can be many generic objects called many times in an application so that placing a conventional breakpoint in a routine of one of these generic objects will result in hundreds of unwanted stoppages prior to occurrence of a desired stoppage. Thus, context sensitive breakpoints were developed and set in certain debuggers to retrieve the sequence of routines in the computer program that are called just prior to reaching the breakpoint. Context sensitive breakpoints locate the specific calls in other objects that relate to the desired stoppage in a particular object and, as a result, may reduce the time consuming and task of setting each breakpoint, as well as the risk that not all relevant calls are found so not all desired circumstances for inducing stoppages may be recognized during debugging.
Despite context-specific breakpoints used in debuggers, too much information may be sent to the debuggers, i.e., the search space is too large for the expected task, and/or the tools return too much information to the developer, i.e., the result space is too massive to be useful, or may not be relevant to the developer's area of interest.
There may be many files of source code open and several debug tools and sessions may be required to debug the application, especially if execution of the application is on multiple remote servers. One approach to support breakpoint operation in different debug sessions on multiple servers is that a user sets the source breakpoints at a client having the debugger's front end that gathers and sends all the set source breakpoints to the various remote debugger engines. For any given breakpoint, each debugger engine searches through the source file names in the objects, e.g., the programs and shared libraries, specified as targets to debug, in order to determine if there is a match of certain properties, such as file name, line number, etc. If there is a match, a breakpoint will be installed, otherwise, the source breakpoint is deferred meaning that the source file name and line number information of the breakpoint are retained in the debug engine but no real breakpoint is set. Later when other objects are loaded during the debug session, the debug engine again attempts to install these deferred source breakpoints. Thus, an analysis tool engine processes many source breakpoints a number of times despite the fact that most of them are not applicable to the source code being debugged.
Some implementations of debugger front ends are able to circumscribe the scope of the project and limit the source breakpoints in the entire IDE. A project contains source code and related files for building a program and maintains a model of the type hierarchy, references and declarations of source elements. As the user changes the source code, the model is constantly updated independently of the builder; that is, when the code is modified, even though an autobuild feature is turned off, the model still reflects the project modifications and contents. As a result, a developer may not be able to debug code that comes from an outside project such as C/C++ standard library headers or code from a JAVA Runtime Environment (JRE). Thus, this solution of limiting the scope of source breakpoints to a particular project does not address the whole problem for a real world application.
Profiling tools may be able to use one or a combination of more than one filter to constrain the scope of the data sent to the profiling tool and/or the data returned to the developer for review. A query filter constrains the data sent to tool engine whereas a view filter constrains the results presented to the software developer. A query result filter constrains the data that is returned to an IDE from a tool engine.
In an IDE, source files are the core point of focus. Developers write and compile source code to create an application. A software developer then uses an IDE to step through the execution of the code to debug, to monitor the performance statistics for parts of that application, and/or to examine the code coverage. At all times, the fundamental object of analysis is the source code itself such that the source code ultimately limits the results of interest to a software developer. Thus, in a sense, query filtering which circumscribes the search space constrains the source code and because source code is common for all such analysis tools, it follows that software developer may be able to define a query and result filter common to all the tools.